Разработка мобильного приложения по учету коммунальных ресурсов. Часть 2

Страницы: 1 2 3

---

2.2. Инфраструктура системы

На рисунке изображена схема инфраструктура системы. ГК – это головной контроллер, который будет выполнять роль сервера. Wi-Fi роутеры

• стандартные сетевые устройства, которые комбинируют в себе свойства двух других сетевых устройств – коммутатора и маршрутизатора. Связь головного контроллера с мобильным приложением будет производиться с помощью Wi- Fi роутера. Связь головного контроллера с системой считывания ресурсов будет производиться с помощью WLAN и/или WPAN протоколов. Передатчик взаимодействует напрямую со счетчиком учета коммунального ресурса.

Рисунок 20. Схема инфраструктуры системы с проводным соединением

На рисунке изображена схема инфраструктуры системы с проводным соединением. Основное отличие заключается в том, что подсистема считывания ресурсов получает доступ к головному контроллеру через проводное соединение. Логика взаимодействия подсистем остается неизменной.

Перед тем как описать какой тип имеет клиент, нужно разобраться в понятиях «толстый» и «тонкий» клиент. «Толстый» клиент – это приложение предоставляющее расширенную функциональность, которая не зависит от сервера. Часть вычислений производится на клиенте, а не на сервере. В системе с «толстым» клиентом сервер представляет собой хранилище данных и не содержит логику обработки данных. «Толстый» клиент обладает широкой функциональностью, имеет возможность многопользовательской работы и имеет офлайн режим. Из минусов – большой размер приложения, сложность обновления с привлечением сил пользователя. Примеры «толстого» клиента:

компьютерные игры, базы данных работающие без доступа в Интернет, браузеры.

«Тонкий» клиент – это приложение, которое совершает от 90% до 99% вычислений на сервере. Данный тип клиента лишь отображает результаты вычислений сервера. «Тонкий» клиент имеет щадящие системные требования и имеет высокий показатель масштабируемости, но требует постоянное подключение к серверу. Примеры «тонкого» клиента: веб-порталы, мессенджеры [22]. Существуют также аппаратные «толстые» и «тонкие» клиенты.

Рисунок 21. Аппаратный «толстый» клиент

Рисунок 22. Аппаратный «тонкий» клиент

Клиент, разрабатываемой системы, будет иметь тип – «толстый» клиент, т.к. если логику обработки запросов заложить в головной контроллер (т.е. использовать «тонкий» клиент), то для вычисления нужны большие вычислительные мощности, которые можно обеспечить при использовании более дорогостоящих устройств. Т.к. планируется уменьшить энергозатраты на головном контроллере, то для выполнения обработки данных лучше использовать устройства пользователей системы.

Рисунок 23. Use Case диаграмма функциональных требований

На рисунке представлена Use Case диаграмма системы учета коммунальных ресурсов. У системы три типа пользователей:

Инженер – это человек от компании, которая поставляет ресурсы; xПользователь – это человек, который использует мобильное приложение для учета ресурсов;

Головной контроллер  –   это   подсистема,  которая  хранит  и принимает данные со счетчиков.

Головной контроллер был выделен в пользователя системы поскольку явно пользуется функциями:

• «Прием данных от передатчика»;
• «Хранение данных»;
• «Предоставление показаний».

2.2. База данных

Головной контроллер может только принимать показания счетчиков, где каждая новая запись ссылается на предыдущую. Такая схема хранения позволяет обеспечить целостность предоставляемых контроллером данных. Система управления базой данных на головном контроллере должны быть SQLite не ниже версии 3.20. Особенность данной СУБД — встраиваемость, т.е. SQLite не использует парадигму клиент-сервер, а представляет собой библиотеку, которая компонуется вместе с программой, из-за чего движок обработки запросов становится составной частью программного обеспечения. Для других СУБД, таких как PostgreSQL, Microsoft Server SQL и Oracle SQL подходят для высоконагруженных, многопользовательских систем. Они обладают хорошими показателями масштабируемости, и имеют подсистему разграничения прав с помощью ролей или пользователей.

Создаваемая система рассчитана на использование внутри одной квартиры. Социальная норма общей жилой площади равна 18 кв.м. на одного из членов семей, но не менее 16 кв.м [23]. Так же на двух членов семьи должно приходиться 42 кв.м. По данным на 2019 г. средняя площадь квартиры на рынке жилья в Москве составляет около 70 кв. м [24]. Исходя из этого можно рассчитать, сколько человек может быть размещено в квартире: от 1 до 4. Для системы 4 пользователя не является высокой нагрузкой.

Рисунок 24. Схема базы данных

На рисунке представлена схема базы данных разрабатываемой системы. Выделены 4 сущности:

xPerson – пользователь системы;

xResourceBill – выставленный счет на оплату израсходованных ресурсов;

xIndicationRecord – показания;

xResourceMeter – счетчик.

Имеется 4 реляционных отношения:

1. Person 1 – M ResourceBill:
   • Person (name, surname, patronymic, address); 2.ResourceBill (serialNumber, costPerUnit, summary, person);
2. ResourceBill M – 1 IndicationRecord:
   • ResourceBill (serialNumber,   costPerUnit,   summary,   person, lastIndication);
   • IndicationRecord (recordUuid, value, recordDate, delta);
3. IndicationRecord M – 1 ResourceMeter:
   • IndicationRecord (recordUuid, device, value, recordDate, delta);

• ResourceMeter (serialNumber, type, verification, addedTime);

ResourceMeter 0 – M ResourceMeter:

ResourceMeter (serialNumber, type, verification, addedTime). 2.ResourceMeterNeighbors (serialNumber, neighborSerialNumber)

Из полученных реляционных отношений создается структура базы данных. В структуру входят файлы (таблицы) и поля таблиц (столбцы). Для удобства работы с записями во все таблицы были добавлены поля id, которые выполняют роль первичного простого ключа таблицы.

Результаты нормализации.

Выделены 5 реляционных отношений (таблиц):

xPerson; xResourceBill; xIndicationRecord; xResourceMeter;

xResoureMeterNeighbors.

При использовании SQLite база данных хранится в файле storage с расширением *.db.

На рисунке представлена физическая модель базы данных. Отображены внешние и главные ключи, типы полей, индексы. Таблица ResourceMeterNeighbors была создана по причине того, что ResourceMeter имеет ссылки на самого себя и имеет радикальное число 0-M, отображающее, что ResourceMeter является необязательной сущностью и для построения корректного отношения, требуется 3 реляционных отношения. Первым и вторым реляционным отношением являются сущности ResourceMeter, а третьим реляционным отношением является ResourceMeterNeighbors, куда вносятся первичные ключи двух других сущностей.

2.3. Схемы работ подсистем

Ниже представлены алгоритмы работы в виде блок-схем:

xБлок-схема алгоритма работы мобильного приложения;

xБлок-схема алгоритма авторизации на головном контроллере; xБлок-схема алгоритма работы пользователя в окне Resource Meter;

xБлок-схема алгоритма добавления Resource Meter.

Рисунок 26. Блок-схема алгоритма работы мобильного приложения

На блок-схеме представлен алгоритм работы мобильного приложения. Процесс отправки запроса на ГК для получения данных: на головной контроллер отправляется HTTP запрос с токеном доступа, который получил пользователь при авторизации. Головной контроллер отвечает на запрос в формате JSON. JSON объект находится в теле HTTP ответа сервера. Мобильное приложение обрабатывает ответ от сервера. Если ответ от сервера является успешным, то JSON Array десериализуется в список объектов класса Block. Иначе пользователю будет сообщено, что головной контроллер не доступен.

После десериализации список объектов отображается на экране пользователя в объекте RecyclerView. Объект RecyclerView – это UI элемент, отвечающий за отображение списков объектов. После отображения элементов мобильное приложение ожидает действия пользователя. Пользователь может закрыть приложение (действие «Нажал на кнопку «Выход» из приложения»), а может заново запросить данные от головного контроллера.

RecyclerView помещен в SwipeRefreshLayout для удобства обновления списка объектов. Интерфейс пользователя не загромождается лишними элементами, такими как кнопка «Обновить». Для обновления данных достаточно потянуть список вниз.

Рисунок 27. Пример ответа от головного контроллера

JSON Array данной структуры головной контроллер отправляет на мобильное приложение. JSON отображает данные хранящиеся в базе данных на головном контроллере.

Рисунок 28. Блок-схема алгоритма авторизации на головном контроллере

На блок-схеме представлен шаблонный алгоритм авторизации в системе, с использованием логина и пароля. Для авторизации пользователя перенаправляет в окно авторизации. Ввода логина и ввод пароля производится с помощью полей ввода данных. Отправка HTTP запроса с логином и паролем выполняется с помощью HTTP клиентов, где в заголовках пакета указывается способ HTTP запроса, на какой URL выполняется запрос, какая версия протокола HTTP используется. Если аутентификация прошла успешна, то сервер авторизует пользователя и в ответе подставляет токен доступа. Иначе пользователю выводится сообщение: «Неверный логин или пароль. Попробуйте еще раз.». Поля для ввода данных очищаются, за исключением логина.

Токен полученный при успешной авторизации используется в дальнейшем при обращении к серверу, чтобы не авторизоваться повторно. Токен доступа имеет срок жизни.

Рисунок 29. Блок-схема алгоритма работы пользователя в окне Resource Meter

На блок-схеме отображен алгоритм работы пользователя в окне ResourceMeter. Перед отправкой запроса на головной контроллер для получение данных мобильное приложение, проверяет, не истекла ли сессия пользователя. Если сессия истекшая, то пользователя отправляет на окно авторизации. После успешной авторизации, токен сессии обновляется, после чего выполняется запрос к головному контроллеру на получение списка имеющихся устройств сбора показаний.

Ответ от сервера приходит в формате JSON. JSON Array десериализуется в список объектов класса ResourceMeter. После чего перерисовывается список RecyclerView, отображающий список систем передачи показаний со счетчиков.

Если пользователь не вышел из приложения, то либо пользователь перешел в другое окно, либо пользователь нажал на кнопку добавления нового устройства. В случае нажатия на кнопку добавления нового устройства, пользователь вызывает подпроцесс «Добавление ResourceMeter». После подпроцесса отправляется запрос на головной контроллер для получения данных об зарегистрированных системах передачи показаний со счетчиков. Это нужно для того, чтобы предотвратить работу с нецелостными данными. Потому что в это же время другой пользователь системы может добавить еще одно устройство, которое не отобразиться у первого пользователя, без обновления списка.

Если пользователь перешел в другое окно вызывается подпроцесс работы в другом окне. Подпроцесс работы в другом окне очень похож на главный процесс мобильного приложения. Токен проверяется на срок жизни. Если токен авторизации истек, то вызывается подпроцесс авторизации на головном контроллере. Иначе отправляется запрос к головному контроллеру, для отображения данных.

Если пользователь нажал на кнопку «Выход из приложения», приложения закрывается.

Рисунок 30. Блок-схема алгоритма добавления Resource Meter

На блок-схеме отображен алгоритм работы пользователя в окне добавления нового Resource Meter. Для ввода данных нового передатчика показаний со счетчика загружается форма ввода данных. Пользователь вводит данные в поля. После ввода данных проводится клиентская валидация. Если введенные данные не валидны, то пользователю выводится сообщение с информацией какие поля невалидны и причины невалидности данных.

В случае успешной клиентской валидации на головной контроллер отправляется PUT запрос. В теле запроса указан JSON, который содержит все необходимые данные для создания записи в таблице ResourceMeter. Перед добавлением в базу данных проводится серверная валидация, чтобы обезопасить систему от некорректных данных, который могли быть получены в результате перехвата и намеренного изменения данных или в результате приема битых пакетов.

Если код HTTP ответа успешный – в этом случае проверяется результат серверной валидации. В случае невалидных данных, выводится сообщение с информацией какие поля не валидны и причины их невалидности. В случае успешной серверной валидации пользователю выводится сообщение, о том, что данные сохранены успешно.

Если код HTTP ответа не является успешным, то пользователю выводится сообщение: «Головной контроллер не доступен. Проверьте соединение с ГК». После этого введенные пользователем данные сохраняются. Данное решение было принято для улучшения UX характеристики мобильного приложения.

В любой момент в алгоритме может произойти завершений алгоритма. Эти ситуации являются исключениями и ошибками устройств. Все исключения, имеющие высокую вероятность возникновения, обрабатываются, чтобы не допустить краха программы, но нельзя обработать исключения: внутренняя ошибка виртуальной машины Android или Java, нехватка оперативной памяти, ошибка запуска приложения.

3. Технический раздел

3.1. Программное и аппаратное обеспечение

3.1.1. Аппаратное обеспечение. Головной контроллер

Аппаратные решение головного контроллера – микрокомпьютеры. Их преимущества заключается в том, что они не занимают много места, могут работать как от кроны, так и от сети, имеют достаточно низкую стоимость в сравнении с обычными компьютерами и имеют множество интерфейсов взаимодействия: USB, GPIO, Ethernet, HDMI.

Рисунок 31. Raspberry Pi 3 Model B+ без корпуса

Аппаратным решением головного контроллера может являться микрокомпьютер Raspberry Pi 3 Model B+. Аппаратные характеристики [25]:

xПроцессор: Broadcom BCM2837, 4 ядра, 1400 МГц;

xОЗУ: LPDDR 2. Объем – 1 ГБ;

xИнтерфейсы:

• HDMI;
• USB 2.0 (4 шт.);

• Camera serial interface;
• Display serial interface;
• Ethernet (8P8C);
• Wi-Fi;
• GPIO (General-purpose  I/O).   Интерфейс   ввода/вывода  общего назначения;
• Bluetooth 2;

xСлот для внешней памяти: Micro-SD.

3.1.2. Аппаратное обеспечение. Передатчики показаний

Передатчики показаний выполняют две функции: xСчитывание показаний со счетчиков ресурсов; xПередачи показаний на головной контроллер.

Для этих целей подходят микроконтроллеры, дополненные платами.

Примеры: Arduino, Raspberry Pi Zero, NodeMCU.

Главное требование, выставляемое к передатчикам – продолжительное время автономной работы (т.е. без постоянного электропитания). Микроконтроллеры, выполняющие роль передатчика, должны поддерживать работу с WPAN и/или WLAN протоколами. Arduino позволяет расширять функционал платы с помощью шилдов. Шилд – дополнительная плата, которая дополняет функционал основной платы Arduino. Пример: Ethernet шилд – позволяет Arduino подключаться к сети, используя семейство технологий пакетной передачи данных Ethernet.

Для разрабатываемой системы будет использоваться Arduino UNO, ввиду того, что данный микроконтроллер является наиболее распространенным в мире и имеет свободное распространение. В свободном доступе имеются схемы распайки и распиновки микроконтроллера.

Характеристики Arduino UNO [26]: xМикроконтроллер: ATmega328; xРабочее напряжение: 5В;

xРекомендуемое напряжение питания: 7-12В;

xПредельное напряжение питания: 6-20В;

xЦифровые входы/выходы: 14 (из них 6 могут использоваться в качестве ШИМ-выходов);

xАналоговые входы: 6;

xМаксимальный ток одного вывода: 40 мА;

xМаксимальный выходной ток вывода 3.3V: 50 мА;

xFlash-память: 32 КБ (ATmega328) из которых 0.5 КБ используются загрузчиком;

xSRAM: 2КБ (ATmega328);

xEEPROM: 1КБ (ATmega328);

xТактовая частота: 16 МГц.

Для того, чтобы можно было воспользоваться специальными протоколами, такими как Ethernet, ZigBee, LoRaWAN нужно воспользоваться дополнительными платами – шилдами. Чтобы сохранять данные на твердотельные накопители, нужно использовать дополнительный шилд.

Рисунок 32 Шилд для взаимодействия с твердотельными накопителями (SD карты)

Взаимодействие с SD картой реализуется через SPI (Serial Peripheral Interface) — последовательный периферийный интерфейс. SPI – это последовательный синхронный стандарт передачи данных в режиме полного дуплекса, предназначенный для обеспечения простого и недорогого высокоскоростного сопряжения микроконтроллеров и периферии.

Рисунок 33. Плата, собранная по схеме Arduino UNO и Ethernet шилд (раздельно)

Рисунок 34. Плата, собранная по схеме Arduino UNO и Ethernet шилд (собрано)

Для передачи данных между передатчиками и головным контроллером можно использовать Protocol Buffers (Protobuf). Данный протокол сериализации/десериализации и передачи структурированных данных был разработан компанией Google. Главной особенностью данного способа обмена сообщениями является то, что осуществляется передача бинарных данных, а не текстовых, как в случае использования XML и/или JSON сериализации.

Рисунок 35. Макет подсистемы сбора и передачи показаний

Рисунок 36. Диаграмма компонентов модулей системы учета коммунальных ресурсов

На диаграмме компонентов отображена зависимость программных модулей. Выделены 3 программных модуля:

xМобильное приложение (Mobile Application);

xГоловной контроллер (Server);

xПередатчик показаний (Meter-MCU).

Модуль «Передатчик показаний» учитывает показания счетчиков и передает их в модуль «Головной контроллер». «Головной контроллер» предоставляет данные для модуля «Мобильное приложение».

3.1.3. Программное обеспечение. Мобильное приложение

Целевыми устройствами пользования являются:

• xМобильные устройства на базе операционных систем Android;
• xМобильные устройства на базе операционных систем iOS.

Для мобильных устройств требуется приложение, написанное на языке Java или Kotlin (для ОС Android), и Swift или Objective-C (для ОС iOS). Для кроссплатформенного приложения используют C# с использованием фреймворка Xamarin или JavaScript/TypeScript с использованием библиотеки React Native.

Для мобильного приложения головной контроллер будет отправлять ответы в формате JSON (JavaScript Object Notation). Данный формат выбран из-за его удобочитаемости как людьми, так и системами.

Для взаимодействия с сервером используется беспроводная связь типа WLAN – Wi-Fi. Wi-Fi поддерживает стек протоколов TCP/IP и сервер принимает HTTP запросы. Для того, чтобы отправлять HTTP запросы на сервер, нужно использовать HTTP клиент. Для Android имеется библиотека Retrofit. Retrofit позволяет разрабатывать HTTP клиенты в декларативном стиле, т.е. разработчик описывает только на какой URL выполняется запрос, какие данные передает на сервер, какие данные ожидает от сервера. Retrofit позволяет сериализовать и десериализовать входные и выходные объекты с помощью популярных библиотек – Jackson и GSON.

Для реализации ORM технологии в разработке Android приложении можно использовать библиотеку ORMLite. ORMLite поддерживает работу с SQLite в Android, легко настраивается, не требует создание дополнительных доменных классов модели, позволяет легко создать класс типа Repository. Поддерживает структурный паттерн проектирования Data-Access-Object (DAO).

3.1.4. Программное обеспечение. Головной контроллер

Головной контроллер выполняет роль сервера. Для роли сервера, с заложенной логикой обработки данных, подходит программное обеспечение типа Web-приложение. Web-приложение обеспечивает прием и отправку

данных с использованием протокола HTTP, а также предоставляет удобный интерфейс для работы с базой данных, если этот интерфейс реализован разработчиком.

Web-приложения на языке Java создаются с помощью двух стеков технологий – Spring или Jakarta (Java EE). Самым популярным стеком технологий является Spring. Проект Jakarta перешел от Oracle к Eclipse Foundation и после этого развитие Java EE приостановилось.

Интерфейс доступа мобильного приложения к данным будет выполнен в стиле REST. Для добавления новых данных принимает PUT или POST HTTP запрос. Для получения данных GET HTTP запрос. Для удаления данных – DELETE HTTP запрос.

3.1.5. Программное обеспечение. Передатчик показаний

Подсистема передачи показаний работает на платформе Arduino Uno. В классической линейке устройств Arduino для платформы Uno применяется микроконтроллер Atmel ACR ATmega328. Для работы с сетью подключены две библиотеки: ArduinoHttpClient и Ethernet. Чтобы отправлять данные на головной контроллер в скетче (исходном файле для Arduino) прописан MAC адрес Ethernet шилда.

// Arduino C/C++

byte mac[] = {0x90, 0xA2, 0xDA, 0x00, 0x4A, 0xE0};

Для отладочной информации и для доступа к внешней флеш-памяти подключена библиотека SPI, отвечающая за доступ к периферийным устройствам.

В исходном коде передатчика показаний определены два основных метода: setup и loop. Метод setup вызывается один раз и выполняет роль инициализирующего метода. Метод loop выполняется бесконечное количество раз, пока работает устройство.

3.2. База данных и СУБД

Использование PostgreSQL, Oracle и похожих СУБД будет излишним для системы, т.к. они спроектированы для больших нагрузок. Также существует требование для ГК – малое энергопотребление. Если использовать PostgreSQL, Oracle или Microsoft Server SQL, то данное требование нарушается, поскольку перечисленные СУБД потребляют большое количество энергии и оказывают большую нагрузку на ЦП устройства. Поэтому лучше всего использовать встраиваемую СУБД – SQLite. Также библиотека для взаимодействия с SQLite и создания баз данных для SQLite встроена во все популярные прикладные языки программирования или поставляется в виде дополнительных библиотек (Java, C#, C++, Python).

В таблице приведены все имеющиеся поля реляционных отношений:

xPerson; xResourceBill; xResourceMeter; xIndicationRecord;

xResourceMeterNeighbors.

Для ключевых полей используется тип INTEGER. В SQLite тип INTEGER может хранится в разных разрядностях (до 8 байт). Если целочисленное число хранится в разрядности 64 бит (8 байт), то это соответствует типу данных long в Java.

Таблица 3. Структура базы данных. Таблицы, поля и типы данных

 

 

На   диаграмме   последовательности   представлено    взаимодействие передатчика   с    головным   контроллером.   Выделены   3    объекта   типа

«Контроллер»:

xГоловной контроллер;

xПередатчик; xСчетчик показаний.

Контроллер «Счетчик   показаний»   предоставляет   показания   для

контроллера «Передатчик» и обновляет свои показания, до тех пор, пока он пригоден для работы. Пригодность работы определяется результатами поверки счетчиков. Поверку приборов учета необходимо производить в установленные сроки, которые указываются в документах технических документах счетчика ресурсов, а также в информационном блоке Единого платежного документа (ЕПД). Поверку счетчиков потребления ресурсов проводит управляющая компания или организация, которая устанавливала прибор учета.

«Передатчик» снимает показания со «Счетчик», после чего проверяет на доступность контроллер «Головной контроллер».

Команды ping-pong используются для обозначения проверки доступности узлов в сети, т.е. для схематичного отображения работы утилиты ping в операционных системах.

Если «Головной контроллер» доступен, то контроллер «Передатчик» отправляет показания на него. «Головной контроллер» отвечает контроллеру

«Передатчик» об успешности обработки запроса. В случае если «Головной контроллер» не доступен, объект «Передатчик» сохраняет данные на внешний носитель. В случае с Arduino внешним носителем является устройство флеш- памяти, например – SD карта.

Контроллеры «Счетчик показаний» и «Передатчик» относятся к единой подсистеме – система сбора и передачи показаний счетчика на головной контроллер

На диаграмме последовательности «Использование мобильного приложения пользователя для мониторинга показаний» выделены 4 объекта:

xПользователь – тип «Пользователь»;

xМобильное приложение – тип «Интерфейс пользователя»;

xГоловной контроллер – тип «Контроллер»;

xБаза данных (БД) собранных показания – тип «Сущность».

«Пользователь» открывает «Мобильное приложение». После запуска

«Мобильное приложение» отправляет запрос на «Головной контроллер» для отображения показаний на экране. «Головной контроллер» обрабатывает запрос от «Мобильное приложение», подготавливает и отправляет запрос к

«БД собранных показаний». В случае если «БД собранных показаний» не доступен, «Головной контроллер» создает сообщение о том, что «Сервер БД не доступен». Данное сообщение отправляется на «Мобильное приложение», где выводится на экран пользователю.

В случае если «БД собранных показаний» доступен, он обрабатывает запрос на языке SQL, полученный от объекта «Головной контроллер». Результат выполнения SQL запросы возвращает на «Головной контроллер».

«Головной контроллер» сериализует результат запроса в список объектов. Если результат выполнения SQL запроса вернул 0 записей из таблицы, то пользователю выводится сообщение: «Нет данных». В ином случае ответ от головного контроллера обрабатывается. На экран пользователя выводятся все имеющиеся записи.

---

Страницы: 1 2 3